RE: how does a term definition include all of : type, id, and alias

On 20 Jul 2014 at 16:19, james anderson wrote:
> On 20 Jul 2014, at 16:02, Markus Lanthaler wrote:
>> I assume you meant this instead, otherwise the JSON snippet below doesn't
>> make much sense as the two blank nodes aren't connected to each other (at
>> least not directly):
> 
> correct. my error.
> 
> i had intended something more like
> 
> _:thing1 <http://example.com/id> <http://example.com/thing#1> .
> _:thing1 <http://example.com/type> <http://example.com/ImportantThing> .
> _:thing1 <http://example.com/feature> _:thing2 .
> _:thing2 <http://example.com/id> <http://example.com/thing#2> .
> _:thing2 <http://example.com/type> <http://example.com/Feature> .
> _:thing2 <http://example.com/characteristic> "low power consumption" .

It's basically the same.


>>> [ { "key" : <http://example.com/thing#1>,
>>>    "class":  <http://example.com/ImportantThing>,
>>>    "features" : [ { "key" : <http://example.com/thing#2>, "class":
>>> <http://example.com/Feature>, "detail": "low power consumption" } ]  } ]
>> 
>> You can use the following frame
>> 
>>  {
>>    "@context": {
>>      "key": "@id",
>>      "class": { "@id": "http://example.com/type", "@type": "@id" },
>>      "features": "http://example.com/feature",
>>      "detail": "http://example.com/characteristic"
>>    },
>>    "features": {}
>>  }
>> http://tinyurl.com/maezvet
> 
> your playground example works on the prepared json, but it is not clear
how
> it applies to the given graph.

It works on any JSON-LD document that serializes that graph. The processing
algorithm is specified in terms of JSON-LD and not an abstract triple
representation if that's your question.


> that is, the "json-ld input" requires an initial transformation from the
original
> rdf graph which i do not yet follow as a consequence of the frame
declaration.

No, not really. The input document is basically flattened (it creates a so
called node map internally) so that it has a deterministic shape. Then that
JSON structure is simply filtered etc. and subtrees are reconstructed.


> the frame also appears to rely on not having specified a type.

I don't understand this question. The doesn't rely on the presence/absence
of a type; only on the presence of the "features" property to find the
desired top-level node.



--
Markus Lanthaler
@markuslanthaler

Received on Monday, 21 July 2014 18:50:26 UTC