Re: inheritance & reuse

On 17/01/2016 4:41 PM, Johnston, Patrick - Hoboken wrote:

>
> PJ> OK, not the answer I was hoping for, but so be it. In terms of the 
> test, its purpose was to allow for a class-agnostic shape, Shape1, to 
> be reused by more than one class-scoped shape (here, Shape2). If I 
> were to make Shape1 a superclass of Class1, I would lose that. I admit 
> I find the way section 1.1 is worded really confusing, and the more I 
> read it the less clear it becomes, in particular around the scope of 
> rdfs:subClassOf. I like Peter’s definition approach in one of the 
> earlier threads. Maybe it would be better to come right out and say 
> that RDFS actually plays no part in the construction of shapes and the 
> shapes graph, but that shapes are able to follow rdfs:subClassOf 
> relationships declared against instances in the data graph. The 
> question is then whether these declarations will be processed if they 
> are made in only the data graph, or the shapes graph, or both? What is 
> really unclear is what of OWL can play in here, if at all, for example 
> instances of owl:Class, definitions which might themselves be imported 
> into the shapes or data graphs using owl:imports.  I don’t want to 
> reignite what seems to have been a painful debate, but not mentioning 
> OWL is doing your readers a disservice. I see a place for both OWL and 
> SHACL in the work I am doing currently (hence the questions), they 
> achieve different ends.

The way that it is intended to work is that it will indeed only consider 
rdfs:subClassOf triples. But there are many different ways of how these 
subclass triples can be produced, including (but not limited to) RDFS 
and OWL inference engines. And even with OWL there are many dialects and 
implementations, e.g. based on rules. The question to me is how much of 
this needs to go into the spec, and how much is better left to tutorials 
and primers.

>
>> 1.
>>
>>
>>
>>  2. Having a shape apply to data graph subclasses of a class in its
>>     scope (inheritance-003, OK).
>>  3. The ramifications of shape merging through reuse, inheritance,
>>     and owl:import.
>>      1. The same shape with overlapping constraints (inheritance-002,
>>         fails for the same reason inheritance-001 fails)
>>      2. Different shapes with the same scope and overlapping
>>         constraints (inheritance-004, OK)
>>      3. Duplicated triples in data graphs (e.g. If there are
>>         instances of shape classes in the owl:import)
>>         (duplication-001, OK)
>>
>
> RDF graphs are sets of triples, so it is not possible to have 
> duplicate triples in a single Turtle file. The Jena parser would 
> already remove the duplicates.
>
> PJ> Agreed that this shouldn't happen, but Jena is just one 
> implementation: other implementations may just leave duplicates in 
> (maybe saying the same thing twice means something to somebody), 
> especially if they originate from different graphs in a quad store, 
> say. Using owl:imports isn’t exactly common behavior in regular 
> linked-data-land, so I think it is worth calling out explicitly.

If a graph implementation preserves and returns duplicate triples then 
the implementation has a serious bug. I don't think we can predict all 
possible bugs.

>
>> 1.
>>
>>
>>
>>  2. The effect of uniqueLang when language is not specified
>>     (uniqueLang-001, fails)
>>
>
> I cannot comment on how common the case you describe will be in 
> practice - having a fallback language and interpreting plain 
> xsd:string literals as having a default language. Maybe you are right, 
> but it will certainly complicate the logic here (e.g. we would need to 
> decide what to do with rdf:HTML triples not just xsd:string). In any 
> case there is the fallback to define your variation of the unique 
> language pattern in SPARQL.
>
> PJ> If the intended scope of sh:uniqueLang are values of type 
> rdf:langString, then the RDF1.1 spec seems to indicate that this also 
> encompasses plain strings (see 
> https://www.w3.org/TR/rdf11-concepts/#dfn-language-tagged-string). In 
> other words, “fred” will validate both as an rdf:langString and as 
> xsd:string.

This is not my understanding. In the text that you quote it states that 
simple literals are syntactic sugar for xsd:string.

Regards,
Holger