lanthaler
Allow compact property names in Node-centric API
It would be very useful for code brevity if the Node class would allow property interaction by compact property names rather than having to use the expanded version everywhere.
Yeah, that’s definitely planned. I’m just not 100% sure yet how to approach it. My current thinking is that the context should be managed via the Document the Node is part of. How do you find that approach?
I'm not too intimate with the code here yet so forgive me if I'm wrong, but I think the context could be managed by the Document, but should be injected into the Node, as there could be many Nodes with different contexts within a single Document.
From an API point of view, it probably makes sense to use different methods for getting properties by their shorthand names, just to avoid any potential collisions. Eg, $node->getCompactProperty('name'). This method could then just reference an array mapping the company property names to the expanded ones, which should be easy to generate when the Node is expanded.
I'm not too intimate with the code here yet so forgive me if I'm wrong, but I think the context could be managed by the Document, but should be injected into the Node, as there could be many Nodes with different contexts within a single Document.
That's exactly the question I'm struggling with. Should there be one context which applies to the whole Document and all its Nodes or one per Node? I'm currently tending to introducing one per Document as otherwise you would have to keep track which context is active for which Node. That would make working with the data very error prone and complex IMO. In other words, a term should expand to exactly the same IRI regardless of which Node it is used on. Do you agree?
From an API point of view, it probably makes sense to use different methods for getting properties by their shorthand names, just to avoid any potential collisions. Eg, $node->getCompactProperty('name'). This method could then just reference an array mapping the company property names to the expanded ones, which should be easy to generate when the Node is expanded.
Hmmm... I see very little potential for collisions so I'm inclined to have just a single method. Also, I think it makes sense to also support compact IRIs (foaf:name) and @vocab here, so, unfortunately, expansion isn't that easy. But all of the processing code is already there. So not a big deal.
To clarify the terminology, what exactly does a Document represent? If the following example was to be returned by a single URL, would it be one Document or two? The use cases for this are perhaps slim, but it is valid.
[
{
"@context": {
"name": "http://xmlns.com/foaf/0.1/name",
"homepage": {
"@id": "http://xmlns.com/foaf/0.1/homepage",
"@type": "@id"
}
},
"name": "Manu Sporny",
"homepage": "http://manu.sporny.org/"
},
{
"@context": {
"ical": "http://www.w3.org/2002/12/cal/ical#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"ical:dtstart": {
"@type": "xsd:dateTime"
}
},
"ical:summary": "Lady Gaga Concert",
"ical:location": "New Orleans Arena, New Orleans, Louisiana, USA",
"ical:dtstart": "2011-04-09T20:00Z"
}
]
Agreed on the second point; supporting compact IRIs and @vocab seems logical.
I thought so. For this to work I think we need to set the context per-Node. Would it make sense to create a Context class and inject an instance into the Nodes' constructor?
The alternative is to just combine the two contexts into one. Perhaps I have different use cases in mind than you have. How do you (intend to) use the Document/Node-based interface to JSON-LD data?
+1 for this enhancement; for my use case a global (= per-document) context would be sufficient
