Re: New Terminology Section

On 7/05/2016 3:31, Karen Coyle wrote:
>
>
> On 5/6/16 9:14 AM, Peter F. Patel-Schneider wrote:
>> I think that instead of reiterating descriptions from RDF 1.1 
>> Concepts and
>> Abstract Syntax, and having errors in at least one of the 
>> descriptions, it
>> would be better to just defer to that document.
>
> In particular, the definition of class is problematic:
>
> Class
> A class is a IRI or blank node representing a set of nodes. SHACL 
> makes no assumption whether a class has certain values for the 
> rdf:type property.
>
> The RDF Schema document says:

We can hopefully continue to avoid referencing the RDF Schema document 
at all. RDF Schema includes certain semantics that are problematic in 
practice and have IMHO not been very successful either. We merely use 
rdfs:subClassOf in a few places, but that's simply because SHACL needs 
to inter-operate with data that has been represented using RDFS 
namespace terms. And I believe in the vast majority of cases, the people 
who have defined classes and subclass relationships did not care about 
the distinction of open world and closed world, or the specific behavior 
of rdfs:domain and rdfs:range either.

My take is that whatever it takes to make progress on the official spec 
is fine with me, as long as we don't mess up the actual language along 
the way. In the end, it's just one of those formal documents that may or 
may not get read once Primers and tutorials get written.

>
> "Resources may be divided into groups called classes. The members of a 
> class are known as instances of the class. Classes are themselves 
> resources. They are often identified by IRIs and may be described 
> using RDF properties. The rdf:type property may be used to state that 
> a resource is an instance of a class."
>
> ... the "class has certain values" doesn't make sense. And I have 
> commented before about the use of "representing" - things either "are" 
> or "are not" but there isn't representation happening, IMO.

Thanks for offering your help on editing (off-list) again, and maybe you 
can point out these fixes on a branch.

>
> The big question, though, in my mind, is whether the use of classes in 
> SHACL follows the definition in RDFS.
>
> In terms of the data graph, the RDFS concept of class is used only in 
> the sense that nodes can be identified as a triple with a predicate 
> "rdf:type" and some designated value.
>
> In the shapes graph, I'm not at all clear on how classes are being 
> used. There are a lot of declared classes that appear to have no 
> functionality within the standard. I'm going to open up an issue so we 
> can try to clarify what classes in SHACL are - that may help us with 
> finding wording.

Details are needed. Not clear what problems you are seeing.

Thanks,
Holger


>
>>
>> I think that it is a bad idea to redefine terms from RDF and RDFS.  
>> Like it or
>> not, some readers of SHACL documents will use the RDF and RDFS 
>> definitions of
>> terms like subclass and superclass when reading SHACL documents even 
>> if these
>> terms are redefined in the SHACL documents.
>
> I agree with this. It means carefully rewording a fair amount of the 
> SHACL document, but it is necessary for clarity.
>
> kc
>
>>
>> peter
>>
>>
>>
>>
>> On 05/05/2016 11:49 PM, Holger Knublauch wrote:
>>> As suggested today, I have added a Terminology section to the very 
>>> start of
>>> the document:
>>>
>>>      http://w3c.github.io/data-shapes/shacl/#terminology
>>>
>>> The primary goal of this section is to provide reasonably formal 
>>> definitions
>>> of the key concepts so that we have this out of the way, and so that 
>>> later
>>> passages of the document can hyperlink to them. I created a HTML coding
>>> convention that makes it easy to maintain such links, allowing us to 
>>> switch
>>> terms (such as replacing "instance" with "SHACL instance") if 
>>> needed. Such
>>> internal links to the definitions show up with a light grey underline,
>>> distinguishable from other hyperlinks.
>>>
>>> The secondary goal of this section is to serve as a quick overview 
>>> for the
>>> casual reader. But my understanding is that this spec is not the 
>>> right place
>>> to serve as a tutorial for beginners, and someone should create a 
>>> Primer with
>>> a different audience in mind.
>>>
>>> The third goal of this section is for us to have a compact space to
>>> collaborate on proper definitions that inform the rest of the 
>>> document. I
>>> would appreciate feedback/iterations on these definitions so that we 
>>> reach a
>>> fixpoint. We could then align the rest of the document once we are 
>>> happy.
>>>
>>> Thanks
>>> Holger
>>>
>>>
>>
>>
>

Received on Saturday, 7 May 2016 05:08:13 UTC