Re: fundamental issues

Hi Peter,

Thanks for compiling this list. I found it helpful. I have a few questions for clarification inline.

> On 12 Feb 2015, at 22:19, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> 1. Modelling
> 
> Is the working group going to produce a modelling language, i.e., a language
> that sits alongside RDFS and is used to describe how information in a domain
> is structured?  The alternative would be to produce a language that
> takes RDF information that already is potentially subject to a modelling
> language and determines whether that information satisfies extra conditions.

I can’t make sense of the distinction that you’re trying to get at here.

For example, I would not describe Resource Shapes as a modelling language. Yet it can be said to “sit alongside RDFS” and it can be said to “describe how information in a domain is structured.”

Also, is OWL a modelling language in your terminology? It appears to fit the “alternative” side of your definition, as it is a language that can be said to “take RDF information that already is potentially subject to a modelling language (RDFS or the schema.org metamodel)” and “determines whether that information satisfies extra conditions”.

Also, if we didn’t have RDFS and OWL, but had let’s say ShExC, then we certainly could do some modelling with it. ShExC perhaps isn’t a very *good* modelling language, but I’m not sure that it’s *not* a modelling language.

How exactly can I tell whether a given language is a modelling language or not?

Or can you explain the distinction you’re trying to get at in a different way?

> 2. Target Data
> 
> Is the working group producing a solution tailored for RDF data, where RDF
> graphs and rdf:type are important; for RDFS data, where rdfs:subClassOf,
> rdfs:subPropertyOf, rdfs:domain, and rdfs:range are also important;

Can you be more clear on what you mean by “important” here? I know what kind of data I want to use shapes on, and all of the above predicates swirl around somewhere in the vicinity of that data, but how do I know if that makes the predicates important?

> for
> Linked Data, where dereferencing and interlinking is important; or for
> services data, where brevity may be important?
> 
> 2. Shapes and Classes
> 
> Are shapes RDF classes, i.e., should shapes be the object of rdf:tyoe
> triples, participate in rdfs:subClassOf relationships, and be the object of
> rdfs:domain and rdfs:range triples?

I assume by “RDF classes” you mean “RDFS classes”? RDF doesn’t have a built-in notion of classes.

The question is only sensible if one already assumes RDFS or OWL semantics. Outside of RDFS/OWL semantics, resources can do all these things without being classes.

> 3. Shape Scope
> 
> What sort of scopes can be given to shapes?  (For example, it is possible to
> state that a particular node in a graph is governed by a shape?  Or all
> instances of a particular class in a graph?  Or all nodes in a graph?)
> 
> It is possible to state that all nodes in a graph must validate against one
> of several shapes?  Or that there must exist a node in a graph that
> validates against a shape?

I agree that this is an open question, but it doesn’t appear to be a fundamental question that must be resolved before the WG can move on to solutions.

> 4. Initiating Validation
> 
> What are the arguments to validation?  It is possible to directly specify
> scopes and shapes in an invocation of validation or do shapes and scopes
> have to be encoded in an RDF graph or other document?

I fail to understand why you consider this question important. Sure, the spec could be written either way, but what other decisions before the WG depend on this?

> Can validation be triggered by events such as invocation of a web
> service or posting by a web service?

The answer to this is obviously: “Sure.”

Was the question whether this WG will specify mechanisms to associate shapes with web services?

Thanks,
Richard




> 
> 
> 
> peter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJU3SbmAAoJECjN6+QThfjzBPEH/0zfpRbTAAOn0LuLVrViFyBG
> uAabONjS/DP1VtsZ/pMurvBVEWWzzNeU/BuX2OfB2fQcvU2nCG/E1gRAxjgn3LJp
> dPDHa8DovkPxs5o9MJOMS8QiN27iHZDmjLcaQaev/zDWwfSvAur8ItrsRyv2t03o
> M9OfHN+e/qk6OBPy6tcsTuwC1ZP0qKqLsj+++IUB69a0bz1x1WBDW6Te9C4dYCWJ
> 39+sbiNSqxwDKqFhSzORc8dBcP+vY59O3Vlxcd1Rq00+EBUiVpEtIKjToMB1N3j9
> 8HJgrA9TiqUB7tvm6dBZ2e5VfsR7lvRDc5YC0SzmXwlRKvAULdrpMwASfLwdqAM=
> =wkz0
> -----END PGP SIGNATURE-----
>

Received on Friday, 13 February 2015 17:56:40 UTC