Re: Service Description Vocabulary

HI Greg,

I am a little bit bothered by the usage of the rdfs:member property
in[1]. It is, syntactically, correct, of course. However, the intention
of rdfs:member was more 'operational' for RDFS reasoning than real usage:

[[[
5.1.6 rdfs:member

rdfs:member is an instance of rdf:Property that is a super-property of
all the container membership properties i.e. each container membership
property has an rdfs:subPropertyOf relationship to the property rdfs:member.
]]] http://www.w3.org/TR/rdf-schema/#ch_member

ie, it is some sort of a helper property for containers.

I think that, from a modeling point of view, using lists would be
cleaner. But then again, we run into our own problems of having
difficulties querying lists...:-(

Sigh. I am not sure whether we should change that, but I though that
airing my (slight) discomfort is worthwhile...

Ivan

[1] http://kasei.us/2009/09/sparql/sd-example.ttl

On 2010-1-15 04:33 , Gregory Williams wrote:
> The last big piece of the service description vocabulary is the modeling of the "available universe" of graphs (using the sd:availableGraphDescriptions term). We had sketched this out at a very high level at the F2F2[1], but the exact modeling was never nailed down.
> 
> Briefly, I see two open issues: what is the rdf:type of the "available universe" node and what is the property that connects this node with the available named graphs. The rdf:type might be something like sd:GraphCollection (being a collection of named graphs, but without a default graph it isn't a sd:Dataset). It's tempting to think that the property should be sd:namedGraph, already used in describing the default dataset, but then the domain of sd:namedGraph can't remain sd:Dataset. The GraphCollection essentially seems like an rdf:Bag, suggesting that the property might be a subproperty of rdfs:member.
> 
> I'd also like to consider renaming the sd:graph property to sd:graphDescription to be more descriptive and to avoid confusion with the introduction of a sd:Graph class.
> 
> I've sketched out what I think a full service description document might look like at [2] and welcome any feedback on these issues.
> 
> thanks,
> .greg
> 
> [1] http://thefigtrees.net/lee/dl/sparql-IMG00009-20091103-1508.jpg
> [2] http://kasei.us/2009/09/sparql/sd-example.ttl
> 
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf